NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/8328

Internet Message Format | 1996-08-05 | 7.2 KB

Path: solon.com!not-for-mail
From: [e-mail] (Peter Seebach)
Newsgroups: comp.lang.c
Subject: Re: What is &Variable (declared as: char Variable[10])?
Date: 3 Mar 1996 00:06:51 -0600
Organization: Usenet Fact Police (Undercover)
Message-ID: <4hbctr$[e-mail]>
References: <4gqpa1$[e-mail]> <4hagqg$[e-mail]>
NNTP-Posting-Host: solutions.solon.com

In article <4hagqg$[e-mail]>,
Reginald W. Sprecher <[e-mail]> wrote:
>1.  A pointer - a pointer is a variable which has as its purpose the
>ability to point to another variable.  One thing that needs to be made
>clear here is that the size of a pointer is always the same no matter
>what type of data the pointer is pointing at ( a pointer to a char and
>an int are the same size).

This is flatly untrue on at least one machine.

>2. address - all variables, including pointers and arrays, have a
>address as to where they live in memory.

This is flatly untrue; register variables do not have an address in
at least some cases, and a compiler may put a variable in a register,
and thus deny it an address, if nothing ever uses its address.

>3. & - the & is the 'give me the address where the indicated variable
>lives in memory' command.  All variables live in memory and therefore
>have an address.  This address can only be resolved at runtime.

Once again, this is untrue.  The second part is also untrue; a clever
compiler can easily determine the address of a variable in advance.
(Especially on Unix, where each process gets its own address space.)

>void main(void)

This is illegal.

>{
>  int a;
>  int b[3];
>  char c[4];
>  char  *a_pointer;

>  a = sizeof(b);
>  a = sizeof(c);

>  a_pointer = c;       // or a_pointer = &c[0]

This is a syntax error.

>  scanf("%s",c);

>}

>1.  The first four statement instructs our program to create memory
>for the indicated variables on the stack.  After these instructions
>are performed our memory looks like:

There is no guarantee that they are on the stack, although this is
how it conventionally happens.  However, they are *not* statements;
they are declarations.  The space is allocated before main begins
executing.  (This makes little practical difference, but is important.
In parcticular, there is no reason to assume that these four objects
are stored in memory in any particular order.)


>                       address     (our name)
>________
>|                |     1000        a  (because a is an int we need 2 bytes to store it)

Please keep lines to less than 80 characters.

Do not assume that ints are 2 bytes; it's often wrong.

>2.  The next thing we encounter is the sizeof instructions.  Be
>carefull here, sizeof looks like a C runtime function, acts like a C
>runtime function but is not a C runtime function.  It is really some
>instructions to tell the compiler to calculate the size of the
>indicated variable at compile time and not at runtime.  It is because
>sizeof is performed by the compiler that the sizeof an array (or any
>variable) can be determined.

Nothing prevents sizeof from being done at runtime in a C interpreter;
it just wouldn't be *useful*.

>3.  After the sizeof are done memory looks like..

The rest of the examples all assume byte order within an int, which is
also stupid.

>Is the name of an array a pointer?  The answer to this, using our
>definition of what a pointer is, is no.  The name of an array is not a
>pointer, but it is what we would call an address.  This is because we
>define all arrays in terms of where they begin in memory.  Therefore
>the following expressions are equal

The name of an array is not an address, either; it is the name of an
array.  If you look at how sizeof() works on it, it's clear that
the array only generates a pointer when one is appropriate.

>This fact therefore makes it possible to intermix the following array
>notation:

>c[1]  or *(c + 1)

No, what makes it possible to intermix those is that the former is *defined*
to be the latter.

>*(array_name + (index * size_of_data_in_array))

Except that this is wrong; it's
    *(array_name + index)
you meant
    *( ((char *) array_name) + (index * sizeof(array_name[0])) )

>4.  Scanf is a function that says it wants 'a pointer' to a variable.
>What it really wants is the address of the variable where it (scanf)
>should put the data it has.  That is why the following scanf
>expressions will put the data in the same place:

>scanf("%s",c);    AND  scanf("%s",a_pointer);

Amazing!  This one is basically correct.  (Except that scanf sometimes
wants other types, some of which are not pointers.)

>1)  Using the name of an array somehow yields or calculates or
>generates the address.

>This is not true. The name of the array is the address of the array.
>The operation is not a calculation or de-referencing, or ....
>I have personally never heard of this 'decay' process.  If you look
>what is really happening inside the code there is no decay process.
>This is because the program always reference an array by its address
>which is the address of the first element in the array.  This same
>pricincipal applies to multi-dimensional arrays as well.

This is entirely bullshit.  The array name, when used in the right
sort of contexts (mostly, "outside of sizeof"), is removed, and replaced
by a pointer to its first element.

It turns into the address of *the first element*, not the address of the
array.  This is different; the address of the array is of type
(pointer to array[N] of T) - the address of the first element is
of type (pointer to T).

>2)  &c is a pointer to something.

>&c is by the above definition is not a pointer, it is an address, and
>specifically it is an address to a variable called c, which is of type
>char, and whose first element is at some address.

Debateable, but it works the same way; &c can be passed to a function
expecting (pointer to type-of-c).

>&c is the address of myarray which is:

>&c == c == &c[0] == 1008 (in our memory map)

But it is of a different type than the others.

>3)  Pointer take on different sizes.

>Pointers only take on a different size when going from one platform to
>another.  If you write a program and define 1000 pointers that can
>point at base data types or your own structures, the size (amount of
>memory) that the pointer varialbe it self consumes is still the same
>size.  Again, the factor here is what is the address space of your
>target system.

This is bullshit, pure and simple.  sizeof(void *) and sizeof(void (*)(void))
are likely to be different.  The only cases where the sizes are guaranteed
to remain the same are sizeof(void *) == sizeof(char *), and
sizeof(T *) == sizeof(const T *) and the like.

On *most common platforms* it may be the case that pointers to different
types are the same size and are represented the same way.  It is not
always true.  My home computer has pointers which are 32 bit pointers
by bytes, and it has pointers which are 30 bit pointers by longwords,
and the top two bits are never used.  The latter are rarely used, but
they're perfectly reasonable pointers.

-s
--
Peter Seebach - [e-mail] - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html